Collegiate Sports Paging System

Requirements Management Plan

Version 1.0

Revision History

Date

Version

Description

Author

October 2, 1999 1.0 Initial release Context Integration
Topics

Introduction Top of page

Purpose

This document presents the manner in which requirements will be tracked through to testing for the project.

Scope

The document pertains to all phases of the project.

Definitions, Acronyms and Abbreviations

See Glossary

References

None.

Requirement Artifacts and Requirement TypesTop of page

Artifact (Document Type) Requirement Type Description
Stakeholder Requests (STR) Request (REQ) Key requests, including Change Requests, from stakeholders
Vision (VIS) Stakeholder Need (NEED) Key stakeholder or user need
Vision (VIS) Feature (FEAT) Conditions or capabilities of this release of the system
Use-Case Model Use Case (UC) Use cases for this release, documented in Rational Rose
Use-Case (UC) Use-Case Detailed Requirement (UC) Individual detailed requirements as specified in the use-case specification
Supplementary Specification (SS) Supplementary Requirement (SUPP) Non-functional requirements that are not captured in the use-case model

Requirement Attributes Top of page

  1. Attributes for FEAT
    1. Status
    2. Set after negotiation and review by the project management team. Tracks progress during definition of the project baseline.

      Proposed Used to describe features that are under discussion but have not yet been reviewed and accepted by the "official channel," such as a working group consisting of representatives from the project team, product management and user or customer community.
      Approved Capabilities that are deemed useful and feasible and have been approved for implementation by the official channel.
      Incorporated Features incorporated into the product baseline at a specific point in time.
    3. Benefit
    4. Set by Marketing, the product manager or the business analyst. All requirements are not created equal. Ranking requirements by their relative benefit to the end user opens a dialogue with customers, analysts and members of the development team. Used in managing scope and determining development priority.

      Critical Essential features. Failure to implement means the system will not meet customer needs. All critical features must be implemented in the release or the schedule will slip.
      Important Features important to the effectiveness and efficiency of the system for most applications. The functionality cannot be easily provided in some other way. Lack of inclusion of an important feature may affect customer or user satisfaction, or even revenue, but release will not be delayed due to lack of any important feature.
      Useful Features that are useful in less typical applications, will be used less frequently, or for which reasonably efficient workarounds can be achieved. No significant revenue or customer satisfaction impact can be expected if such an item is not included in a release.
    5. Effort
    6. Set by the development team. Because some features require more time and resources than others, estimating the number of team or person-weeks, lines of code required or function points, for example, is the best way to gauge complexity and set expectations of what can and cannot be accomplished in a given time frame. Used in managing scope and determining development priority.

    7. Risk
    8. Set by development team based on the probability the project will experience undesirable events, such as cost overruns, schedule delays or even cancellation. Most project managers find categorizing risks as high, medium, and low sufficient, although finer gradations are possible. Risk can often be assessed indirectly by measuring the uncertainty (range) of the projects teams schedule estimate.

    9. Stability
    10. Set by analyst and development team based on the probability the feature will change or the team’s understanding of the feature will change. Used to help establish development priorities and determine those items for which additional elicitation is the appropriate next action.

    11. Target Release
    12. Records the intended product version in which the feature will first appear. This field can be used to allocate features from a Vision document into a particular baseline release. When combined with the status field, your team can propose, record and discuss various features of the release without committing them to development. Only features whose Status is set to Incorporated and whose Target Release is defined will be implemented. When scope management occurs, the Target Release Version Number can be increased so the item will remain in the Vision document but will be scheduled for a later release.

    13. Assigned To
    14. In many projects, features will be assigned to "feature teams" responsible for further elicitation, writing the software requirements and implementation. This simple pull down list will help everyone on the project team better understand responsibilities.

    15. Reason

    This text field is used to track the source of the requested feature. Requirements exist for specific reasons. This field records an explanation or a reference to an explanation. For example, the reference might be to a page and line number of a product requirement specification, or to a minute marker on a video of an important customer interview.

  2. Attributes for REQ
    1. Status
    2. Set after negotiation and review by the project management team. Tracks progress during definition of the project baseline.

      Proposed Used to describe requests that are under discussion but have not yet been reviewed and accepted by the "official channel," which in this case is the Change Control Board.
      Approved Capabilities that are deemed useful and feasible and have been approved for implementation by the Change Control Board.
      Rejected Requests that reflect requirements that are not needed for this release of the product, and have hence been rejected by the Change Control Board.
      Incorporated Requests incorporated into the product baseline at a specific point in time.
    3. Benefit
    4. Set by Marketing, the product manager or the business analyst. All requirements are not created equal. Ranking requests by their relative benefit to the end user opens a dialogue with customers, analysts and members of the development team. Used in managing scope and determining development priority.

      Critical Essential requests. Failure to implement means the system will not meet customer needs. All critical requests must be implemented in the release or the schedule will slip.
      Important Requests important to the effectiveness and efficiency of the system for most applications. The functionality cannot be easily provided in some other way. Lack of inclusion of an important request may affect customer or user satisfaction, or even revenue, but release will not be delayed due to lack of any important feature.
      Useful Requests that are useful in less typical applications, will be used less frequently, or for which reasonably efficient workarounds can be achieved. No significant revenue or customer satisfaction impact can be expected if such an item is not included in a release.
    5. Effort
    6. Set by the development team. Because some requests require more time and resources than others, estimating the number of team or person-weeks, lines of code required or function points, for example, is the best way to gauge complexity and set expectations of what can and cannot be accomplished in a given time frame. Used in managing scope and determining development priority.

    7. Risk
    8. Set by development team based on the probability the project will experience undesirable events, such as cost overruns, schedule delays or even cancellation. Most project managers find categorizing risks as high, medium, and low sufficient, although finer gradations are possible. Risk can often be assessed indirectly by measuring the uncertainty (range) of the projects teams schedule estimate.

    9. Stability
    10. Set by analyst and development team based on the probability the request will change or the team’s understanding of the feature will change. Used to help establish development priorities and determine those items for which additional elicitation is the appropriate next action.

    11. Assigned To
    12. The implementation of this request is assigned to a member of the project team.

    13. Reason

    This text field is used to track the source of the request. Requirements exist for specific reasons. This field records an explanation or a reference to an explanation. For example, the reference might be to a page and line number of a product requirement specification, or to a minute marker on a video of an important customer interview.

  3. Attributes for NEED
    1. Status
    2. Set after negotiation and review by the project management team. Tracks progress during definition of the project baseline.

      Proposed Used to describe needs that are under discussion but have not yet been reviewed and accepted by the "official channel," such as a working group consisting of representatives from the project team, product management and user or customer community.
      Approved Capabilities that are deemed useful and feasible and have been approved for implementation by the official channel.
      Incorporated Needs being met by the product baseline at a specific point in time.
    3. Effort
    4. Set by the development team. Because some needs require more time and resources than others, estimating the number of team or person-weeks, lines of code required or function points, for example, is the best way to gauge complexity and set expectations of what can and cannot be accomplished in a given time frame. Used in managing scope and determining development priority.

    5. Risk
    6. Set by development team based on the probability the project will experience undesirable events, such as cost overruns, schedule delays or even cancellation. Most project managers find categorizing risks as high, medium, and low sufficient, although finer gradations are possible. Risk can often be assessed indirectly by measuring the uncertainty (range) of the projects teams schedule estimate.

    7. Stability
    8. Set by analyst and development team based on the probability the need will change or the team’s understanding of the need will change. Used to help establish development priorities and determine those items for which additional elicitation is the appropriate next action.

    9. Target Release
    10. Records the intended product version in which the need will first be met. This field can be used to allocate features from a Vision document into a particular baseline release. When combined with the status field, your team can propose, record and discuss various features of the release without committing them to development. Only needs whose Status is set to Incorporated and whose Target Release is defined will be met. When scope management occurs, the Target Release Version Number can be increased so the item will remain in the Vision document but will be scheduled for a later release.

    11. Reason

    This text field is used to track the source of the need. Requirements exist for specific reasons. This field records an explanation or a reference to an explanation. For example, the reference might be to a page and line number of a product requirement specification, or to a minute marker on a video of an important customer interview.

  4. Attributes for UC
    1. Status
    2. Set after negotiation and review by the project management team. Tracks progress during definition of the project baseline.

      Proposed Used to describe use-cases that are under discussion but have not yet been reviewed and accepted by the "official channel," such as a working group consisting of representatives from the project team, product management and user or customer community.
      Approved Use-cases that are deemed useful and feasible and have been approved for implementation by the official channel.
      Incorporated Use-cases incorporated into the product baseline at a specific point in time.
    3. Benefit
    4. Set by Marketing, the product manager or the business analyst. All requirements are not created equal. Ranking use-cases by their relative benefit to the end user opens a dialogue with customers, analysts and members of the development team. Used in managing scope and determining development priority.

      Critical Essential use-cases. Failure to implement means the system will not meet customer needs. All critical use-cases must be implemented in the release or the schedule will slip.
      Important Use-cases important to the effectiveness and efficiency of the system for most applications. The functionality cannot be easily provided in some other way. Lack of inclusion of an important feature may affect customer or user satisfaction, or even revenue, but release will not be delayed due to lack of any important feature.
      Useful Use-cases that are useful in less typical applications, will be used less frequently, or for which reasonably efficient workarounds can be achieved. No significant revenue or customer satisfaction impact can be expected if such an item is not included in a release.
    5. Effort
    6. Set by the development team. Because some use-cases require more time and resources than others, estimating the number of team or person-weeks, lines of code required or function points, for example, is the best way to gauge complexity and set expectations of what can and cannot be accomplished in a given time frame. Used in managing scope and determining development priority.

    7. Risk
    8. Set by development team based on the probability the project will experience undesirable events, such as cost overruns, schedule delays or even cancellation. Most project managers find categorizing risks as high, medium, and low sufficient, although finer gradations are possible. Risk can often be assessed indirectly by measuring the uncertainty (range) of the projects teams schedule estimate.

    9. Stability
    10. Set by analyst and development team based on the probability the use-case will change or the team’s understanding of the use-case will change. Used to help establish development priorities and determine those items for which additional elicitation is the appropriate next action.

    11. Target Release
    12. Records the intended product version in which the use-case will first appear. This field can be used to allocate use-cases from a Use Case Survey document into a particular baseline release. When combined with the status field, your team can propose, record and discuss various use-cases of the release without committing them to development. Only use-cases whose Status is set to Incorporated and whose Target Release is defined will be implemented. When scope management occurs, the Target Release Version Number can be increased so the item will remain in the Vision document but will be scheduled for a later release.

    13. Assigned To
    14. In many projects, use-cases will be assigned to teams responsible for further elicitation, writing the software requirements and implementation. This simple pull down list will help everyone on the project team better understand responsibilities.

    15. Reason

    This text field is used to track the source of the requested use-case. Requirements exist for specific reasons. This field records an explanation or a reference to an explanation. For example, the reference might be to a page and line number of a product requirement specification, or to a minute marker on a video of an important customer interview.

  5. Attributes for SUPP
    1. Status
    2. Set after negotiation and review by the project management team. Tracks progress during definition of the project baseline.

      Proposed Used to describe supplemental specifications that are under discussion but have not yet been reviewed and accepted by the "official channel," such as a working group consisting of representatives from the project team, product management and user or customer community.
      Approved Capabilities that are deemed useful and feasible and have been approved for implementation by the official channel.
      Incorporated Supplemental specifications incorporated into the product baseline at a specific point in time.
    3. Benefit
    4. Set by Marketing, the product manager or the business analyst. All requirements are not created equal. Ranking requirements by their relative benefit to the end user opens a dialogue with customers, analysts and members of the development team. Used in managing scope and determining development priority.

      Critical Essential specification. Failure to implement means the system will not meet customer needs. All critical features must be implemented in the release or the schedule will slip.
      Important Specifications important to the effectiveness and efficiency of the system for most applications. The functionality cannot be easily provided in some other way. Lack of inclusion of an important specification may affect customer or user satisfaction, or even revenue, but release will not be delayed due to lack of any important feature.
      Useful Specifications that are useful in less typical applications, will be used less frequently, or for which reasonably efficient workarounds can be achieved. No significant revenue or customer satisfaction impact can be expected if such an item is not included in a release.
    5. Effort
    6. Set by the development team. Because some specifications require more time and resources than others, estimating the number of team or person-weeks, lines of code required or function points, for example, is the best way to gauge complexity and set expectations of what can and cannot be accomplished in a given time frame. Used in managing scope and determining development priority.

    7. Risk
    8. Set by development team based on the probability the project will experience undesirable events, such as cost overruns, schedule delays or even cancellation. Most project managers find categorizing risks as high, medium, and low sufficient, although finer gradations are possible. Risk can often be assessed indirectly by measuring the uncertainty (range) of the projects teams schedule estimate.

    9. Stability
    10. Set by analyst and development team based on the probability the specification will change or the team’s understanding of the specification will change. Used to help establish development priorities and determine those items for which additional elicitation is the appropriate next action.

    11. Target Release
    12. Records the intended product version in which the specified attribute or feature will first appear. This field can be used to allocate specifications into a particular baseline release. When combined with the status field, your team can propose, record and discuss various specifications of the release without committing them to development. Only specifications whose Status is set to Incorporated and whose Target Release is defined will be implemented. When scope management occurs, the Target Release Version Number can be increased so the item will remain in the supplemental specification document but will be scheduled for a later release.

    13. Assigned To

In many projects, specified attributes or features will be assigned to teams responsible for further elicitation, writing the software requirements and implementation. This simple pull down list will help everyone on the project team better understand responsibilities.

Traceability Criteria Top of page

  1. Criteria for FEAT
  2. Features will be traced to use cases.

  3. Criteria for REQ
  4. Requirements will be traced to use cases and/or supplemental specifications.

  5. Criteria for NEED
  6. User needs will be traced to use cases and/or supplemental specifications.

  7. Criteria for UC
  8. Use-cases will be traced to test cases.

  9. Criteria for SUPP

Supplemental specifications will be traced to test cases.

 

Figure -1 - Traceability diagram

Copyright  © 1987 - 2000 Rational Software Corporation

Display Rational Unified Process using frames

Rational Unified Process